The goals for the ASC design:

Full inteferometer alignment control using wavefront sensor control for most loops, and slow dither control for spot positions. Arm loops like DHARD and CHARD will be the highest bandwidth loops (up to 10 Hz), MICH 1-3 Hz bandwidth, PRC2 and INP1 <1 Hz bandwidth. No commissioning work (by me) has been done to develop soft control. The arm BPC control can still likely be used. Higher bandwidth soft control will need to be designed.

However, the full realization of this goal has not been achieved. Here is the current status of all loops.

• Arm loops commissioned and closed: DHARD P, DHARD Y, CHARD P, CHARD Y. Feedback to all test masses MN and TM stage, with MN stage very low bandwidth DC control with integrator
  • CHARD loops use REFL sensors, DHARD loops use AS sensors
  • Current bandwidth is very low. All loop designs are engaged with lower gain than desired due to lock stability issues. My current hypothesis is that higher bandwidth control is not compatible with the noise in the sensors.
  • Notch filters and low pass filters to reduce noise reinjection make higher bandwidth control difficult because of loop stability.
• PRMI loops commissioned and closed
  • INP1 feeds back to IMMT2, uses REFL sensors. Feedback directly to IMMT2 with integrator
    • INP1 P is very stable and has no issues. INP1 Y is currently engaged with an offset. This offset is only present when CHARD Y is engaged. I think a method to reduce this offset is to close the CHARD Y loop and check the INP1 Y sensors and look for a new combination that reduces the offset
  • PRC2 feeds back to PR3, uses POP sensors, feedback to PR3 TM stage with integrator at TM stage
    • closing this loop is very challenging. The handoff from the local TM OL Damping control is challenging and might cause a glitch that causes a lockloss. It is also possible that PR2 would be a better mirror to control the PRC alignment, but the sensing of PR2 is not very good. PR2 might be better sensed on POP with an f2-f1 sensor (28 MHz).
  • MICH feeds back to BS, uses POP sensors, feedback to IM and TM stage, with IM low bandwidth control and integrator
    • The current MICH sensors have offsets in pitch and yaw. MICH engagement is fairly robust, but it would be best to check if there is better sensing without offsets.

All these loops have been tested and closed. The biggest challenge right now is that closing the loops can be very disruptive to the lock. A method of closing the loops with low bandwidth and increasing the gain as the signals converge should be implemented in guardian code. Once the loops are closed, the interferometer stability is improved.

I think it is best to prioritize the loop closing process alongside the commissioning of the SOFT loops. The loop offsets are not ideal, but are less urgent. In parallel, the noise level of the wavefront sensors should be investigated. A question to answer is: how much of that noise is real motion, versus reinjected sensor noise from local controls, versus ground motion, etc.? The answer to this question will help determine what kind of loop bandwidth is ultimately necessary.

The IMC Trans laser power hasBeen higher than normal for the past few weeks. This likely explains the larger number of locklosses at the PRMI state. I think some check should be added to the LSC LOCK guardian that checks the IMC output power, and adjusts the power to the nominal 1.2 W, or refuses to move forward in the locking sequence when the power is too high. We don't understand why the IMC laser power has changed.

There has been limited ASC commissioning today due to the length of time locking takes.

I have now set the guardian to engage all four hard loops, the MICH loop, and the INP1 with much lower bandwidth. If I get a chance, I will test slowly ramping up the gains until we achieve the design bandwidth. I caused one lockloss by engaging the PRC2 loop, so I think I did not lower the bandwidth enough to avoid this problem. I will try a lower gain next.

The most recent locks have made it to the "engage WFS DC" state, but a centering PZT on POP is saturated. There is a lockloss before I can fix the problem. There is no ASC feedback on at this time, so I am not sure what is causing the lockloss.

I plan to leave the interferometer locking continuously to PRFPMI RF Locked (ASC engaged) to collect more lockloss statistics, and test the ASC engagement reliability.

I am adding a 20 dB gain decrease to the PRM pitch filter to test if this improves the lock acquisiton rate.

During many of the locks we have had today, PRM often goes to the Isolated state. This seems to occur when PRM is brought into alignment for PRMI locking. The guardian does not re-request "lock acquisition" if this happens, so it has to be done by hand. I think the engagement of the integrator on the TM stage must kick the suspension enough to briefly saturate. Once the suspension is brought back into alignment, everything is fine and locking proceeds.

As a reminder, this is likely happening because I implemented a new design of the PRM OLdamping loop with increased low frequency gain.

Today is a relatively quiet day for ground motion- no earthquakes and the microseismic motion has been mostly below the 50th percentile, according to the BLRMS screen in the control room. I took a deeper look at the locking patterns to see if I could see any change in locking success. From a purely subjective point of view, locking the IFO to the point of being able to do commissioning work is a time consuming process because there can be so many locklosses.

Here is some actual data from today:

Within a 2 hour and 10 minute period, there were 37 lock attempts. Commissioning work essentially begins once the IFO reaches the PRFPMI locked with 3F state (guardian state number 1200). At this point, the PRMI is moved to the 1 FSIG sensors (state 1205), and then the ASC WFS can start the engagement and testing. Out of those 37 lock attempts, only six lock attempts actually achieved guardian state 1200. Of those 6 PRFPMI lock successes, only five allowed commissioning work- one lock reached state 1200 and then immediately lost lock after.

Of those final five locks where commissioning took place, four of the locklosses were caused by commissioning work (testing new loop engagement strategies). One lockloss appears to have occurred independent of the ASC work- ASC was in a steady state at the time and there was no oscillation in ASC preceding the lockloss.

I think that it would be beneficial to spend some time investigating why the locking process is so slow and so fragile. Commissioning will cause locklosses, but based on this one period of investigation, that only accounts for 13% of the locklosses. It also doesn't seem like these locklosses can be explained by ground motion. The PNC for the X arm has been enabled for all of these lock attempts.

I have attached a plot of the LSC LOCK guardian state number, marking the period of time I chose to do this quick analysis. It might be worthwhile to note that a majority of these locklosses seem to occur around state 1005- Engage PRMI 3F. It will probably also help to set up some programs that can collect actual statistics of the locklosses, so bigger trends can be investigated.

[Tanaka, Capote]

We have created some error in the initial alignment process, and we can't figure out how to fix it. We successfully completed an initial alignment, but did not save the final oplev values properly. We were unable to lock after that, so we went back to DOWN and tried to rerun the initial alignment. However, the GRX alignment was locked well for a TEM00 mode. This means that when we proceeded to the IRX lock, we could not lock IRX and we saw no IR beam at all. This made it difficult to tell which way to move the mirrors to find the IRX alignment. I tried reverting the oplev values several times and it seemed to do nothing. I followed the "revert oplev" process detailed. I tried reverting to just before the initial alignment tonight and early today and it made no different in the GRX alignment or IR alignment. I tried making large movements in ITMX, PR3, PR2, IMMT1 and IMMT2 to see if I could find any IR flashes in the arm to lock X with IR. I was unsuccessful. We can see that the GRX beam is well centered on ETMX, but again, there is no presence of the IR beam anywhere on ITMX or ETMX.

Another earthquake has begun so I cannot fix this problem tonight. 

For some reason, whenever we try to go to initial alignment, this causing a problem with the PRM suspension that can only be fixed manually. The PRM suspension experiences a large kick, and then switches wildly between gaurdian states, while the guardian reports "PRM going to isolated state". However, nothing changes and the guardian continues to wildly switch between states and saturating the suspension. To stop this process, I hold the output on the TM damping and clear history immediately. Then I manually select the guardian to go either "Isolated" to let the suspension calm down, or "misaligned". "Misaligned" is the guardian state the PRM must be in for the initial alignment process.

I think something is going wrong in the process of disengaging the TM integrators but I can't tell what because it happens so fast.

Turns out this was a guardian problem. Both the new and old filters were engaged by the guardian, which is clearly incorrect. I have deleted all the old filters in favor of the new filters so this error does not occur again.

I modified the pitch loops design to match the old loop design gain at low frequency. I undid all changes to the yaw loops.

In lock, pitch should have FM2, 3, 5 and 9 engaged. Yaw should have FM6, 7, and 9 engaged.

What kind of fluctuation was witnessed?

Also the proper filters to engage for the old design would be FM6, 7 and 9.

The new design should be FM2, 3 and 9.

Using ITMY as an example, I measured the open loop gain of the MN OLDAMP P loop. This loop acts as the main local control for the test masses until the handover to the WFS control. Since we are having no success locking with high ground motion, I figured I would check what kind of low frequency suppression is in this loop. After looking at the measurement, I figured we could do much better. I updated the loop to have a plant compensator. Although the loop has "damp" in its name, remember this is a distinct loop from the actual damping loops on the MN stage. Therefore, this loop is more about stability and low frequency suppression instead of mode suppression. Furthermore, because we handover the MN control to the WFS when the ASC engages, we don't have to worry about the noise considerations of the loop. It can be higher bandwidth to maintain control.

I was successful in designing a loop with much more low frequency suppression, and a reduction in other instabilities. I removed all the notches present in the filter banks. In short, the notches go overboard. For many of these filters, anywhere between 2 and 4 different filter banks, all named some variation of "notch" are engaged. Opening up these filters, you see anywhere between 2 and 10 notch filters within each module. Some of them are duplicate. In my opinion, it seems notches are added with little thought and oversight. This definitely compromises the stability of these loops, and quickly becomes confusing. I encourage everyone to work harder to a) clearly label notch filters (such as labeling "vertical mode notches" or "11 Hz notch") and b) check the current notch filters engaged to see if that notch is already present. If you find yourself adding 10 notches to a filter bank that already has 10 notch filters engaged, carefully consider the necessity.

I propagated this new loop design to all test masses and engaged it. I tried to do the same process for yaw, but it got late and I decided to stop for the night.

The attached screenshot shows the old measured loop shape in blue and the new loop shape in red. This loop will have more noise than the old loop design, but it will not be engaged in science mode, so that is ok.

I was immediately suspicious when we easily locked FPMI for the Q measurement, but had struggled all day to lock PRFPMI for commissioning work. I decided to check the PRM local controls and make sure everything is stable. I first checked the IM damping loops. I measured L, T, R, P, Y. The only one that looked bad was P. There was very little phase margin for the loop, and as a result about 10 dB of gain peaking around 5 Hz. I reshaped the lead filter and low pass cutoff. I also removed an unnecessary notch filter to gain back more phase. I noticed that all the damping loops for PRM had "notch_test" and "notch" engaged. The same notch frequency was notched in both, but the notch in "notch" (FM6), was lower Q. I have turned off all the FM6 filters.

I have attached a comparison of the PRM IM P damping loop before and after my changes. The loop looks much more stable and there is about a factor of 3 less motion at a few Hz than before.

While holding in DOWN, I measured the PRM TM P and Y OLDAMP. Pitch also had a little more than 10 dB gain peaking. The yaw loop was better, but I decided both loops could use a bit of redesign. I believe my new design is better- less gain peaking for both and improved low frequency suppression. I have attached screenshots of the OLG measurement of PRM TM OLDAMP P and Y.

For all plots in the attachement, the blue reference traces show the old loop design measurement and the red live reference traces show the new loop design measurement.

During the lock acquisition process, ITMX and ITMY suspensions are taken to the low noise state during the PRMI lock acquisition. This seems too early in the locking process, in my opinion. Right now, all the guardian does is engage the analog low pass for the TM stage. However, we need larger actuation range on the TM stage during ASC engagement. Once all the controls are engaged, the LSC LOCK guardian should have a state to engage lownoise control for all suspensions (if necessary). Now ITMX and ITMY will stay in the LOCK ACQUISITION state throughout locking. A state will need to be added later in the guardian process to engage the lownoise suspension control.

I re-engaged the PNC for the X arm to see if that helps the locking process. Locking is very unstable today because of the high ground motion. I turned on the output of the PNC servo for both X and Y arm. The Y arm servo still goes nowhere- the actuation matrix values are zero. Ushiba-san tells me this is on purpose because the PZTs for PNC Y are broken.

I  have been thinking more about the issues that arise when engaging the ASC loops. The loops have been proven to be stable, but often engaging the loops themselves can cause locklosses. I think this is due to the fact that at the start of engagement, the error signal of the loops is large and slightly offset to the desired operating point. So when the loops are engaged, the drive to the suspension is too large. Not necessarily large enough to saturate, but large enough that the impulse can cause a lockloss.

This was an issue encountered at LIGO and solved by implementing what we call "smooth limiters", which is a limiter to the error signal at the start of loop engagement, that ensure the amount of counts drive to the suspension stays within a reasonable value. Once the error signals converge to some desired value, the limiter is disengaged and the full loop is able to engage. To read about this implementation, see LHO alogs LHO:44133 and LHO:44261.

One particular failure has occured when engaging ASC MICH Y. When we engage MICH Y, we disengage the local oplev damping control of the beamsplitter and engage the WFS control. The control design for the oplev control and the WFS control is exactly the same, however the error signals are different. When engaging MICH Y, the control signal output is a factor of 5 greater than the control signal of the oplev control. This is probably too large and therefore disastrous for the interferometer to handle. I believe a similar problem sometimes occurs when engaging the PRC, INP or arm ASC. Sometimes the engagement works and the lock survives the initial large impulse. Sometimes, the lock does not survive.

This problem seems to be occuring more often for the yaw than pitch. Maybe the yaw alignment is further offset from the ideal operating point than the pitch alignment. Currently, I am working around this issue by not engaging the yaw ASC control, but this is not a sustainable solution because the yaw alignment is then poorly controlled. This also explains why sometimes engaging these loops does work.

Implementing this kind of limiter will require updates to the model and probably some troubleshooting. It may not be something I can implement during my time here. I am going to try to work around this for now by engaging these loops with very low gain and then slowly stepping up the gain as the signals converge.

It appears that there is some issue with the laser. Trending to the lockloss preceding this failure, it looks like the laser failure caused the lockloss. The lockloss occurred during locking ALS DARM (state 210 of LSC_LOCK). At the time of the lockloss, the laser power drops from about 20W to 1 W.

There is generally very high ground motion today, especially in the 300 mHz - 10 Hz bands. This seems to be impacting locking, as most locking attempts result in locklosses somewhere between finding IR to PRFPMI locked. Many locklosses go down and report "waiting for reducing the effects of an earthquake" for a few minutes before relocking.

Based on the forecast screens, this is predicted to only get worse through Wednesday.

I have been able to increase the bandwidth of the arm ASC loops by implementing a smoother cutoff filter, a chebyshev around 10 Hz. This prevents excess noise in DARM just above 10 Hz where the elliptical cutoff was, since the elliptic cutoff is very sharp.

The BS and PR3 alignment signals have been working inconsistently:

• The MICH loops seem to require offsets. The yaw offset seems inconsistent, so while troubleshooting the various alignment problems, I have returned to using BS dither for yaw only while engaging the MICH P loop. I'm hoping that if I can stabilize the yaw alignment elsewhere, it will be easier to identify what is going on with the MICH Y signal.
• PRC2 P and Y are also unstable for different reasons. Sometimes, engaging them causes a glitch that causes an immediate lockloss. The error signals are well centered, so it doesn't seem to be an offset problem.

The CHARD Y loop has now been closed using REFL WFS 45 as the error signal. The estimated bandwidth is about 1 Hz.

I have not been able to troubleshoot the issues with MICH and PRC2. There have been a lot of locklosses during the process of acquiring PRFPMI, so relocking after every test takes a while. This work will pick up on Monday.

Looks like I am actually mistaken about the lockloss- the drop in OMC trans occurs after the lockloss. The attached screenshot shows the guardian is already transitioning to down when the OMC trans reaches zero. I will look for other possible causes of this lockloss. The arm transmission also appears stable at this time.

Yes, that's a good point! I am trying to ensure the stabilization of the arm transmission now. I will check the few locklosses we have had and see if the OMC trans drop corresponds with the arm transmission drop consistently.

The handover is still successful, but there is a consistent lockloss after the handover when the OMC trans output drops briefly to zero. Ushiba-san and I thought this might be a DARM RMS issue, so we engaged a boost at low frequency. Even with this boost, there is still this type of lockloss.

I am still not sure of the issue, so I will stop attempting DC readout for the time being and focus on stabilizing the alignment signals.

Ushiba-san looked at the most recent lockloss with me, and he thinks that the OMC transmission very briefly dropped just below the trigger threshhold value. The trigger value is 5, and the transmission briefly reached 4.8. We ae lowering the trigger threshhold to 3. Hopefully that will give us enough room to avoid the sideband.

Twice the OMC has locked on some higher order mode. I think while scanning, the OMC flashes a 00 mode, which the scan picks up on, but then the PZT offset chosen somehow selects an offset for a different mode. I don't understand enough about the OMC scan process to understand why this happens, but I figured I should note it. If this happens, I take the OMC LSC guardian down by hand and rerun.

Now, we have successfully locked the OMC on 00 and performed the handover, but there is a lockloss a few seconds later.

[Ushiba, Capote, Nakano]

We have tried to go to DC readout several times today. The first lockloss occurred because we did not properly match the gains from TRAS to OMC during the handover. We ran the transfer function to match the gains and chaged the OMC_DC gain, but didn't realize that same value had already been saved into the guardian as the input matrix value. The second time, we set up the gains properly, but lost lock during the ramp, which we determined was because we were ramped the gain downstream from an integrator. We updated the guardian to engage the null filter in TRAS instead of ramping the gain off at the input matrix. The third time we lost lock, we successfully handed over control to the OMC, but then there was a saturation in the OMC signal. We have turned of the whitening stage to see if this helps. After another lockloss, we tried reducing the DARM offset to see if that helps the saturation further.

Ushiba-san also performed a single arm alignment to the OMC to see if this would improve the locking. So far we are not sure if this has made any difference.

We are continuing to try, but there are many locklosses occurring in between for random reasons so it is slow going.